<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1"><title id="bq20941">CREATE DOMAIN</title><body><p id="sql_command_desc">Defines a new domain.</p><section id="section2"><title>Synopsis</title><codeblock id="sql_command_synopsis">CREATE DOMAIN <varname>name</varname> [AS] <varname>data_type</varname> [DEFAULT <varname>expression</varname>]
       [ COLLATE <varname>collation</varname> ] 
       [ CONSTRAINT <varname>constraint_name</varname>
       | NOT NULL | NULL 
       | CHECK (<varname>expression</varname>) [...]]</codeblock></section><section id="section3"><title>Description</title>
      <p><codeph>CREATE DOMAIN</codeph> creates a new domain. A domain is essentially a data type
        with optional constraints (restrictions on the allowed set of values). The user who defines
        a domain becomes its owner. The domain name must be unique among the data types and domains
        existing in its schema. </p>
      <p>If a schema name is given (for example, <codeph>CREATE DOMAIN myschema.mydomain
          ...</codeph>) then the domain is created in the specified schema. Otherwise it is created
        in the current schema. </p>
  
  <p>Domains are useful for abstracting common constraints on fields into
a single location for maintenance. For example, several tables might
contain email address columns, all requiring the same <codeph>CHECK</codeph>
constraint to verify the address syntax. It is easier to define a domain
rather than setting up a column constraint for each table that has an
email column.</p>
      <p> To be able to create a domain, you must have <codeph>USAGE</codeph> privilege on the
        underlying type.</p></section><section id="section4"><title>Parameters</title>
      <parml>
        <plentry>
          <pt><varname>name</varname></pt>
          <pd>The name (optionally schema-qualified) of a domain to be created. </pd>
        </plentry>
        <plentry>
          <pt><varname>data_type</varname></pt>
          <pd>The underlying data type of the domain. This may include array specifiers. </pd>
        </plentry>
        <plentry>
          <pt>DEFAULT <varname>expression</varname></pt>
          <pd>Specifies a default value for columns of the domain data type. The value is any
            variable-free expression (but subqueries are not allowed). The data type of the default
            expression must match the data type of the domain. If no default value is specified,
            then the default value is the null value. The default expression will be used in any
            insert operation that does not specify a value for the column. If a default value is
            defined for a particular column, it overrides any default associated with the domain. In
            turn, the domain default overrides any default value associated with the underlying data
            type.</pd>
        </plentry>
        <plentry>
          <pt>COLLATE <varname>collation</varname></pt>
          <pd>An optional collation for the domain. If no collation is specified, the underlying
            data type's default collation is used. The underlying type must be collatable if
              <codeph>COLLATE</codeph> is specified. </pd>
        </plentry>
        <plentry>
          <pt>CONSTRAINT <varname>constraint_name</varname></pt>
          <pd>An optional name for a constraint. If not specified, the system generates a name.
          </pd>
        </plentry>
        <plentry>
          <pt>NOT NULL</pt>
          <pd>Values of this domain are normally prevented from being null. However, it is still
            possible for a domain with this constraint to take a null value if it is assigned a
            matching domain type that has become null, e.g. via a left outer join, or a command such
            as <codeph>INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE
              false))</codeph>. </pd>
        </plentry>
        <plentry>
          <pt>NULL</pt>
          <pd>Values of this domain are allowed to be null. This is the default. This clause is only
            intended for compatibility with nonstandard SQL databases. Its use is discouraged in new
            applications.</pd>
        </plentry>
        <plentry>
          <pt>CHECK <varname>(expression)</varname></pt>
          <pd><codeph>CHECK</codeph> clauses specify integrity constraints or tests which values of
            the domain must satisfy. Each constraint must be an expression producing a Boolean
            result. It should use the key word <codeph>VALUE</codeph> to refer to the value being
            tested. Currently, <codeph>CHECK</codeph> expressions cannot contain subqueries nor
            refer to variables other than <codeph>VALUE</codeph>. </pd>
        </plentry>
      </parml></section><section id="section5"><title>Examples</title><p>Create the <codeph>us_zip_code</codeph> data type. A regular expression test is used to verify
        that the value looks like a valid US zip code. </p><codeblock>CREATE DOMAIN us_zip_code AS TEXT CHECK 
       ( VALUE ~ '^\d{5}$' OR VALUE ~ '^\d{5}-\d{4}$' );</codeblock></section><section id="section6"><title>Compatibility</title><p><codeph>CREATE DOMAIN</codeph> conforms to the SQL standard. </p></section><section id="section7"><title>See Also</title><p><codeph><xref href="ALTER_DOMAIN.xml#topic1" type="topic" format="dita"/></codeph>, <codeph><xref
            href="./DROP_DOMAIN.xml#topic1" type="topic" format="dita"/></codeph></p></section></body></topic>
